Systems and methods for multi-region encryption/decryption redundancy

ABSTRACT

Methods and systems for encrypting and decrypting data comprising sending sensitive information to a first cryptographic processing system in a first cloud region for encryption with a first key encryption key generated by and stored by the first cryptographic processing system. The first encrypted sensitive information received from the first cryptographic processing system is stored in a first database. The sensitive information is also sent to a second cryptographic processing system in a second cloud region different from the first cloud region for encryption with a second key encryption key generated by and stored by the second cryptographic processing system. The second encrypted sensitive information received from the second cryptographic processing system is stored in a second database. If the first encrypted sensitive information cannot be decrypted by the first cryptographic processing system, the second encrypted sensitive information is sent to the second cryptographic processing system.

RELATED APPLICATION

The present application claims the benefit of U.S. Pat. No. 10,805,070,which was issued on Oct. 13, 2020, which claims the benefit of U.S.Provisional Patent Application No. 62/410,148, which was filed on Oct.19, 2016, both of which are assigned to the Assignee of the presentinvention, and are incorporated by reference herein.

FIELD OF THE INVENTION

Multi-region encryption/decryption redundancy and, more particularly,multi-region encryption/decryption through the use of cryptographicprocessing systems, such as key management services and/or hardwaresecurity modules in each region.

BACKGROUND OF THE INVENTION Cloud-Based Applications

Cloud-based hosting providers, such as Amazon Web Services, Inc.,Seattle, Wash. (“AWS”), provide servers, networking, firewalls, securityappliances, and other infrastructure through a scalable cloud model byinstalling physical versions of those infrastructure elements indatacenters located around the world, and providing access to theinfrastructure over the public internet by creating “virtual” versionsof the elements. For example, an AWS server is a virtual interface,written in software, which has the characteristics of a physical server.Similarly, an AWS router and an AWS firewall are virtual versions of aphysical router and physical firewall, respectively, with the same levelof configuration and customization associated with an on-site, hardwaresystem.

An important benefit of using a cloud-based solution is scalability, asit is easier to add server capacity than to install new physicalhardware at an on-site datacenter. Other benefits include decreasedmaintenance costs, and redundancy. Most cloud providers host identicaldatacenters in different “regions,” where regions may be defineddifferently by different cloud providers, and allow customers to set-uptheir infrastructure in one or more regions. Data center regions may begeographic based or not.

Most of AWS's infrastructure provides additional redundancy within eachregion in case of failure within a region by creating multipleAvailability Zones (“AZs”). Each region may be comprised of many AZs,each representing additional co-located datacenters in the samemetropolitan area to minimize latency. AZs may use different powersupply companies, and/or different network providers, etc., to preventshared failure.

While AZs provide a good degree of redundancy, a common best practice isto also employ region redundancy when hosting business-criticalinformation and/or applications in the cloud. Region redundancy in caseof failure is the virtual equivalent of a disaster recovery process. Ifa physical datacenter were to flood, suffer a power failure or fire, oranother such failure or breakdown, for example, data may be backed upand stored in backup storage devices.

Security

Computational security relies heavily on the concept of keys, which areused to encrypt and decrypt data and to ensure that data received overthe internet has not been interfered with or intercepted in transport. Acommon method to ensure secure communication between two parties orservers, for example, is the use of RSA public-private key encryption.In RSA public-private key encryption, each party generates a privatekey, which is kept secret, and a public key, which may be shared. Thepublic and private keys generated by each party (referred to as a “keypair”) have a computational relationship such that data encrypted withthe public key can only be decrypted by the corresponding private key.The public and private keys may be both generated based on the sameprime number, for example.

Using this model, if Bob wants to send a secure message to Alice, whohas a public key and a computationally related private key, he does thefollowing:

Bob asks Alice for her public key, or looks it up if already known;

Bob encrypts the message with Alice's public key, creating a securemessage;

Bob sends the secure message to Alice; and

Alice decrypts the secure message using her private key, which only sheshould know.

Only Alice's private key can be used to decrypt Bob's message since itwas encrypted using the corresponding, computationally-related publickey.

A common approach to ensure secure storage of private keys and othersensitive data is to employ a cryptographic hardware device, such as ahardware security module (“HSM”). The HSM generates and stores keys,such as symmetric encryption keys that may be used to encrypt anddecrypt data for clients. HSMs are inherently secure devices that useextensive hardening techniques to securely generate and store keys. Thehardening techniques include never storing plaintext master keys ondisk, not persisting them in memory, destroying a key if a tamper eventis detected, and/or limiting the systems that can connect to the device,for example. As with other cloud infrastructure elements, AWS provides a“virtual” HSM or a key management service (“KMS”) that is backed by ahardware HSM in a given Amazon region datacenter to create and controlkey generation and data encryption/decryption based on the generatedkeys. Generated keys never leave their respective HSM or KMS, and canonly be accessed by specific servers and authenticated users. A highlysecure algorithm, such as an RSA key generation algorithm, may be usedto generate the client keys by the KMS or the HSM, for example. As usedherein, HSMs, KMSs, and other such devices and services are referred toas “cryptographic processing systems.”

Respective clients may send data to the KMS or HSM for encryption by oneof the client encryption keys. The encrypted data is returned to theclient. When the client desires that encrypted data be decrypted, theclient sends the encrypted data to the KMS or HSM, which decrypts thedata with the same client key used to encrypt the data, and sends thedecrypted data to the client.

SUMMARY OF THE INVENTION

In embodiments of the invention, sensitive information, such as thesensitive information discussed above, is encrypted based on respectivekey encryption keys generated by KMSs or HSMs in different regions, toincrease fault tolerance and add redundancy in case of a failure of aKMS/HSM in one region. The data encrypted by each KMS/HSM may be storedin the secure database and data decrypted by each KMS/HSM is stored involatile memory. If first encrypted data encrypted by a first KMS/HSM ina first region cannot be decrypted by the first KMS/HSM, correspondingsecond encrypted data that was encrypted by a second KMS/HSM in a secondregion may be decrypted by the second KMS/HSM. One or more additionalKMS/HSM in one or more additional regions may be provided.

In accordance with a first embodiment of the invention, a method ofencrypting and decrypting data is disclosed comprising sending sensitiveinformation to a first cryptographic processing system in a first cloudregion for encryption with a first key encryption key generated by andstored by the first cryptographic processing system. The first encryptedsensitive information received from the first cryptographic processingsystem is stored in a first database. The sensitive information is alsosent to a second cryptographic processing system in a second cloudregion different from the first cloud region for encryption with asecond key encryption key generated by and stored by the secondcryptographic processing system. The second encrypted sensitiveinformation received from the second cryptographic processing system isstored in a second database. The first database and the second databaseare the same database, and the first and second database may be securedatabases, or a secure database. The first cryptographic processingsystem may comprise a key management service and/or a hardware securitymodule, and the second cryptographic processing system comprises a keymanagement service and/or a hardware security module.

The first encrypted sensitive information and the second encryptedsensitive information may be formed into an object that is stored in thedatabase or databases. The sensitive information may comprise aplurality of types of sensitive information and the method furthercomprise forming the first encrypted sensitive information and thesecond encrypted sensitive information of each type of sensitiveinformation into respective objects that are stored in the one or moredatabases. A respective object of encrypted sensitive information of afirst type may be retrieved from the database and parsed to identify thefirst encrypted sensitive information of the first type encrypted by thefirst cryptographic processing system, and to identify the secondencrypted sensitive information of the first type encrypted by thesecond cryptographic processing system. The first and second encryptedsensitive information of the first type are sent to the firstcryptographic processing system for decryption.

In one example, the first encrypted sensitive information retrieved fromthe first database is retrieved and sent the first cryptographicprocessing system for decryption. If the first decrypted sensitiveinformation is received from the cryptographic processing system withina period of time, then the decrypted sensitive information is stored inmemory. If the first decrypted sensitive information is not receivedfrom the cryptographic processing system within a period of time, thenthe second encrypted sensitive information is retrieved from the seconddatabase and sent to the second cryptographic processing system fordecryption. If the second decrypted sensitive information is receivedfrom the cryptographic processing system within a period of time, thenthe second decrypted sensitive information in memory. The memory may bevolatile memory, for example.

The first sensitive information may also be sent to a thirdcryptographic processing system in a third cloud region for encryptionwith a third encryption key. The third encrypted sensitive informationis stored in a third database, which may be the same as the second andfirst databases. If the second encrypted information is not receivedfrom the second cryptographic processing system within a second periodof time, then the third encrypted sensitive information is retrievedfrom the third database and sent to third cryptographic processingsystem for decryption. If the third decrypted sensitive information isreceived from the third cryptographic processing system, then it isstored in memory, which can be volatile memory, for example. The firstencrypted private key is retrieved from the database and sent to thefirst cryptographic processing system for decryption with the first keyencryption key. The received decrypted private key is stored in volatilememory. If the first decrypted private key is not received from thecryptographic processing system within a period of time, then the secondencrypted private key is retrieved from the database and sent to thesecond encrypted private key to the second cryptographic processingsystem for decryption. If the first decrypted sensitive information isreceived from the cryptographic processing system within a period oftime, then the first encrypted sensitive information is stored involatile memory. The sensitive information may also comprise saltsand/or encryption keys. The sensitive information may comprise a binarylarge object comprising a plurality of concatenated salts.

In accordance with a second embodiment the invention, a system forencrypting and decrypting data is also disclosed comprising at least onedatabase and a processing device configured to operate as describedabove with respect to the first embodiment.

In accordance with another embodiment of the invention, card informationon cards, including the card number and other card information, such asthe cardholder name, card expiration date, card verification value(“CVV”), and other information that may be provided on magnetic tracksof the card, as described in ISO/IEC 7813, or on an EMV card, forexample, is also encrypted. EMV is a technical standard for smartpayment cards, which include an integrated circuit or chip embedded intothe card. EMV stands for Europay, MasterCard, and Visa, who created thestandard. Smart payment cards are referred to as “EMV cards,” “chipcards,” or integrated circuit (“IC”) cards or ICCs, for example. Thecard information from the magnetic tracks or EMV cards may be encryptedby a selected one of a plurality of a secure keys, such as an AES key,for example.

Embodiments of the invention may be used in cloud-based systems ornon-cloud based systems. As discussed above, hardware security modules(“HSMs”), and key management services (“KMSs”), and other such devicesand services, are referred to herein as “cryptographic processingsystems.”

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is block diagram of an example of a card payment processingenvironment 100 in which embodiments of the invention may beimplemented;

FIG. 2 is a block diagram of an example of a Merchant, which isrepresentative of the Merchants in FIG. 1 ;

FIG. 3 is a more detailed block diagram of the processing center of FIG.1 ;

FIG. 4 is a simplified, schematic representation of a portion of thesystem of FIG. 1 , showing the KMS, the SCDE, and the network;

FIG. 5 is a flow diagram of a method of encrypting and decryptingsensitive information (also referred to herein as an RES), in accordancewith an embodiment of the invention;

FIG. 6 is a flowchart of an example of key creation for a new merchant,in accordance with an embodiment on invention;

FIG. 7 is a flowchart of an example of a method for retrieving a newlycreated merchant private key from the secure database;

FIG. 8 is a flowchart of an example of a method for preparing salts andkeys for encrypting sensitive information, such as personal accountnumbers (“PANs”) and plain text card data, for example, in accordancewith an embodiment of the invention;

FIG. 9 is an example of a method of decrypting and storing in RAM othermerchant RESs′, the blob RES′, and the AES key RESs′, for use during aboot process;

FIG. 10A-10B is a flowchart of an example of a method of the processingthe card information received from the PIN pad terminal, by theprocessing center;

FIG. 11 is a flowchart of an example of PAN encryption to form theencrypted card ID, in accordance with an embodiment of the invention;

FIG. 12 is a flowchart of an example of a method for encrypting plaintext card data in Step 875 of FIG. 10B, in accordance with theembodiment of the invention;

FIG. 13 is flow chart of an example of housekeeping, in accordance withan embodiment of the invention;

FIG. 14 is a block diagram of an example of a portion of a card paymentprocessing system that provides region redundancy, in accordance with anembodiment of the invention;

FIG. 15 is an example of a flowchart of the encryption of the blob ofsalts and the AES keys, in a region redundant system of FIG. 14 , inaccordance with the embodiment of the invention;

FIG. 16 is an example of a process for encrypting merchant private keysin the redundant system of FIG. 14 , in accordance with an embodiment ofthe invention; and

FIGS. 17A-17B is an example of the flowchart of an example of a bootprocess in the system of FIG. 14 , in accordance with an embodiment ofthe invention.

DETAILED DESCRIPTION

FIG. 1 is block diagram of an example of a card payment processingenvironment 100 in which embodiments of the invention may beimplemented. The card may be a credit card, debit card, or gift card,for example. The environment 100 includes Merchants 1, 2, 3 . . . N arecoupled to a network 110, such as the internet, for example. Aprocessing center 150 is also coupled to the network 110. Transactiondata is sent from the Merchants 1, 2, 3 . . . N to the processing center150 via the network 110 for processing. The processing center 150 may bein a cloud-based environment provided by a cloud hosting provider suchas the Amazon Web Services provided by Amazon, Inc., Seattle, Wash., forexample. Amazon Web Services is compliant with payment credit industrydata security standard (“PCI DSS”), for example. Other PCI DSS compliantcloud-based environments may also be used. Alternatively, the processingcenter 150 may comprise physical hardware, such as computers andservers, coupled to the network 110. In this example, the Merchants 1,2, 3 . . . N are separate entities from the processing center 150. Alocal data center may also use embodiments of the invention to provideinternal security, whose components are coupled via a local areanetwork, for example. The processing center 150 may be a paymentgateway, such as Index Systems, Inc. San Francisco, Calif., for example,which provides customer analytics and payment gateway services to theMerchants 1, 2, 3 . . . N and other parties in FIG. 1 .

FIG. 2 is a block diagram of an example of a Merchant 1, which isrepresentative of the Merchants 2, 3 . . . N. The Merchant 1 includesone or more points of sale (“POS”) terminals 120 and respective PIN padterminals 130. Pairs of POSs 120 and PIN pads terminals 130 may beprovided in respective checkout lanes 1, 2 . . . N for example, at thelocation of the Merchant 1. The PIN pad terminal 130 providestransaction data to a router 140 wirelessly or via a cable, for example.The router 140 forwards the transaction data to the network 110 througha firewall 145. The PIN pads 130 include a processor 132 and memory 134.The processor may be a microprocessor, for example. The PIN pad 130typically also includes a magnetic stripe reader (not shown) to readdata on the tracks of a magnetic stripe on a card. The PIN pad terminals130 may also include a reader (not shown) to receive and interact withan EMV card. The PIN pad terminal 130 receives purchase data from thePOS terminal 120 and card information from the purchaser's card, whichmay be swiped or inserted into the PIN pad terminal 130, depending onwhether the card is an EMV card or not, for example.

A payment application (“Payment App”) 136 is stored in the memory 134 ofthe PIN pad 130. The payment App 136 controls operation of the processor132 of the PIN pad terminal 130 including encrypting purchase data andpayment information, transmitting the encrypted data and information tothe processing center 150, and providing a personalized checkoutexperience including the identification of relevant loyaltyoffers/discounts that could be calculated prior to paymentauthorization, for example. The Payment App 136 may be downloaded to thePIN pad terminals 130 of the Merchant 1 after the Merchant 1 registerswith the processing center 150, as discussed further below. The PIN padterminals 130 may be a Verifone MX915 or Verifone MX925, available fromVerifone Holdings, Inc., San Jose Calif., or an Ingenico iSC250 orIngenico iSC480, available from Ingenico Solutions, Rowlands Castle,England, for example.

Returning to FIG. 1 , a plurality of payment processors 160 a, 160 b,160 c are also coupled to the network 110. More or fewer paymentprocessors 160 a-160 c may be provided. After processing the transactiondata in accordance with embodiments of the invention, as discussed inmore detail below, authorization to accept payment via the profferedcard is requested by the processing center 150 from the appropriatepayment processor 160 a-160 c. Authorization is requested in anencrypted, HTTPS envelope that is sent to the respective paymentprocessor 160 a-160 c via the network 110, for example. The respectivepayment processor 160 a-160 c stores transaction data to provide daily,weekly, and/or monthly summary reports to Merchants 1, 2, 3 . . . N. Therespective payment processor 160 a-160 c also validates aspects of thedata received from the PIN pad terminal 130 and passed on by theprocessing center 150, as is known in the art.

After validation, the payment processor 50 routes the data to the cardbrand 165 of the card, such as Visa or MasterCard, for example, also inan encrypted HTTPS envelope, for verification of the card number andexpiration date, transaction approval/denial, and other operations knownin the art. Only one block 165 is shown to represent the multiple cardbrands, for ease of illustration. If the card data is verified by thecard brand 165, the card and transaction data are routed by the cardbrand to the bank 168 that issued the credit card to check credit limitsand perform other operations known in the art, also in an encryptedHTTPS envelope. Only one block 168 is shown to represent multiplepossible issuing banks, for ease of illustration.

If the issuing bank 165 approves the transaction, it sends anauthorization or approval message back along the chain, to the cardbrand 165, payment processor 160 a, processing center 150, to therespective PIN pad 130 of the Merchant 1, via the network 110 in eachstep, in respective encrypted HTTPS envelopes. The PIN pad 130 receivingthe authorization then accepts the payment via the card and completesthe transaction. If the card brand 165 or the issuing bank 168 docs notverify the card data or authorize the transaction, respectively, adenial message is returned along the same chain to the payment processor160 a and processing center 150, via the network 110, to the respectivePIN pad 130. The PIN pad 130 will not then accept the card payment. Analternative form of payment, such as another card, may then berequested.

As shown in FIG. 1 , the processing center 150 includes an applicationsserver 170 and a secure card data environment (“SCDE”) server 180. Theapplication server 170 provides customer and merchant analytics andperforms gateway functions. The SCDE server 180 processes sensitiveinformation, such as card and transaction data. In accordance with anembodiment of the invention, the SCDE server 180 only communicates withthe network 110 through the applications server 170. This protectsagainst accidental data leakage. Multiple applications servers 170and/or multiple SCDE servers 180 may be provided. In this example, theapplication server 170 and the SCDE server 180 are virtual serversforming a virtual private cloud (“VPC”). The servers 170, 180 may alsobe physical servers or computers in a non-cloud based environment.Operation of the processing center 150 is described in more detailbelow.

In accordance with an embodiment of the invention, a key managementservice (“KMS”) 200 provided by the cloud hosting provider is used togenerate one or more keys to encrypt sensitive information provided bythe SCDE server 180 of the processing system 150. The KMS 200 may beprovided part of a service 200, such as the KMS provided by Amazon WebServices (“AWS”), for example. Other cloud hosting providers includeMicrosoft, Inc., Redmond, Wash., and Google, Inc., Mountain View,Calif., for example.

The KMS 200 from AWS is a virtualized version of a cryptographichardware device, such as hardware security module (“HSM”), where theprocessing device and secure storage are located. The KMS 200 uses atleast one processing device and a secure database (not shown), such as aprocessing device and secure database of an HSM, to generate and secure,store one or more encryption keys for clients. The KMS 200 uses at leastone processing device and a secure database (not shown) to generate andsecure, store one or more encryption keys for clients. The KMS 200 maycommunicate with the network 110 via an application interface (notshown), for example, as is also known in the art. While the KMS 200 isreferred to throughout this description, embodiments of the inventionmay also be implemented with any virtual or non-virtual cryptographicprocessing system that generates and securely stores encryption keys,such as an HSM, for example.

FIG. 3 is a more detailed block diagram of the processing center 150.The processing center 150 includes a firewall 250 that monitors datapackets received from and sent to the network 110 in accordance withrules defined by the processing center 150 as is known in the art. Theapplications server 170 comprises at least one processing device 260 andat least one database, including a transactions database 270. Theprocessing device 260 may be a computer or microprocessor, for example.The secure card data environment (“SCDE”) comprises at least oneprocessing device 280, volatile memory 290, such as random access memory(“RAM”), and a secure database 300. As above, the processing device 280may be a computer or microprocessor, for example. The secure database300 stores sensitive card holder data, including the credit card numbersand merchant private keys, for example, as discussed further below.

In one example, to provide extra security for the encrypted data storedin the secure database 300, only the processing device 280 can accessthe secure database 300, and only the applications server 170 can accessthe processing device 280. To further protect decrypted sensitiveinformation, such information may only be stored in RAM 290 or othervolatile memory and may be deleted after use. The processing device 280may use the RAM 290 or other such memory (not shown) while performingcalculations and other functions, as described below. The securedatabase 300 may be a MongoDB available from MongoDB, Inc., New York,N.Y., for example. The MongoDB database is a document-oriented,non-relational non-structured query language (non-SQL or NoSQL)database. Other types of databases, such as an SQL database or arelational management database, may also be used. Examples of SQLrelational databases include MySQL, an open source relational databasesystem available from MySQL AB, Sweden, for example, and PostgreSQL, anobject relational database management system available from thePostgreSQL Global Development Group, for example. Any of these databasesmay be made secure by limiting access to the database, for example, asdescribed above.

In accordance with an embodiment of the invention, sensitive informationis encrypted by the KMS 200 with a key, referred to a key encrypting key(“KEK”) that is generated by the KMS. The KEK is shown schematicallywithin the KMS 200 in FIG. 1 . The KEK in this example is a symmetrickey, such as 256-bit advanced encryption standard (“AES”) key. Otherhighly secure encryption techniques for creating reversible keys mayalso be used to create the KEK. The KEK is only used and stored by theKMS 200. The KEK never leaves the KMS 200—data must be sent to it forencryption and decryption. The KEK is therefore protected, helping tomaintain security by making attacks, hacks, data theft, etc. of theencrypted data more difficult or infeasible.

FIG. 4 is a simplified, schematic representation of a portion of thesystem 100 of FIG. 1 , showing the KMS 200, the SCDE 180, and thenetwork 110. The KEK 202 generated by the KMS 200 is also shownschematically within the KMS in FIG. 4 . The KEK 202 may be generated inresponse to a request for a key by the processing center 150, forexample. Amazon Web Services, for example, provides an on-line consolevia a web interface for requesting KEKs. Sensitive information, referredto herein as a region encrypted secret (“RES”), is shown schematicallyin the processing device 280 of the SCDE 300. One or more KEKs 200 maybe generated and stored by the KMS 200 for the processing center 150, asrequested by the processing center. For example, the processing center150 may request different KEKs to encrypt different types of sensitivedata. The KMS 200 also generates a KEK reference (“KEK^(R)”) for eachKEK and sends it to the processing device 280 of the processing center150 for storage in the secure database 300. The KEK^(R) identifies therespective KEK used to encrypt the respective RES so that when theprocessing center 150 sends the encrypted RES to the KMS 200 to bedecrypted, the KMS can identify the KEK used to encrypt the respectivedata. The KEK^(R) may identify the location of the respective KEK in theKMS 200, for example.

FIG. 5 is a flow diagram of a method of encrypting and decryptingsensitive information (also referred to herein as an RES, as discussedabove) in accordance with an embodiment of the invention. In FIG. 5 ,the network 110 and the application server 170 are not shown for ease ofillustration, but it is understood that communication between the KMS200 and the SCDE 280 is through the KMS interface, the network 110, andthe applications server 170.

To encrypt the sensitive information (RES), the RES is sent by theprocessing device 280 of the SCDE 180 to the KMS across the network 110,as indicated by line 1. The RES may be sent in a secure envelope orpackage, such as via a secure HTTP (“HTTPS”) connection along atransport layer security version 1.2 (“TLS 1.2”), for example. The RESis encrypted by what is referred to as an encryption/decryption engine204 of the KMS 200 with the KEK, as indicated by line 2. It is notedthat the encryption/decryption engine is a functional representation ofthe operation of the KMS 200 and is not meant to show the exactoperation of the KMS 200. How the KMS 200 encrypts and decrypts databased on the KEK and KEK^(R) are not aspects of the present inventionand are known in the art.

The encrypted RES is now referred to as RES′ where (′) indicates thatthe RES is encrypted. The RES′ is associated with a reference KEK(“KEK^(R)”) that identifies the KEK 202 used to encrypt the respectiveRES, as discussed above. The RES′ and the KEK^(R) are returned to theprocessing device 280 of the SCDE 180 (via the network 110 andapplications server 170, which are not shown in this view), along line3.

The received RES′ and the associated KEK^(R) are sent by the processingdevice 280 of the SCDE 180 to the secure database 300, for storage, asindicated by line 4. When the RES (non-encrypted data) is needed, asdiscussed below, the RES′ (encrypted RES) and associated KEK^(R) areretrieved from the secure database 300 by the processing device 280, asindicated by line 5, and sent to the KMS 200, as indicated by line 6. Itis noted that when the processing center 150 has only requested one (1)KEK, it may not be necessary to return the KEK^(R) to the KMS 200 sincethe KMS can identify the one KEK based on the processing center thatprovided the provided the data to be decrypted. Returning the KEK^(R)with the RES′ in such circumstances is, therefore, optional. If theprocessing center 150 has requested multiple KEKs, to encrypt differenttypes of RESs, for example, it would be necessary to send the respectiveKEK^(R) with the RES′ to be decrypted.

In this example, the KEK 202 used to initially encrypt the RES isidentified by the KMS 200 based on the KEK^(R), and the RES′ isdecrypted by the encryption/description engine 204 based on the KEK 202to generate the RES, as indicated by line 7. The decrypted RES′ isreturned to the processing device 280 of the SCDE 180, as indicated byline 8, and stored in the RAM 290, as indicated by line 9, via thenetwork 110 and the applications server 170.

The RES is retrieved from the RAM 290 when needed by the SCDE 180. Ifthe processing center 150 suffers a power failure or other catastrophicfailure, for example, the RES is lost, protecting the unencryptedsensitive data. As noted above, the corresponding encrypted RES (RES′)is maintained in the secure database 300, in an encrypted, secure form.

In one example of the card payment processing environment of FIG. 1 ,the types of RES's that may be encrypted and decrypted by the KMS 200,include a merchant private key assigned to respective merchants, a“blob” of salts used in card encryption, and AES keys used in cardencryption. The merchant private key is used to decrypt data encryptedby the PIN pad terminal 130 based on the associated merchant public key.The salts and AES keys are used in the encryption of the card number (orpersonal account number) and the card data, respectively, as discussedfurther below. In this embodiment, the card number and card datathemselves are not encrypted by the KMS 200.

Merchant Registration

FIG. 6 is a flowchart 400 of an example of key creation for a newmerchant, in accordance with an embodiment on invention. To participatein the card processing environment 100, a merchant, such as the Merchant1, registers with the processing center 150. In one registrationexample, the merchant provides identifying information and storelocations, for example, in Step 410. The Merchant 1 typically has orobtains PIN pads 130 on its own. Registration may be conducted via awebpage of the payment processing center 150, for example.

The processing center 150 then generates a public/private key pair forthe Merchant 1, in Step 420. In one example, the public/private key pairis generated by an RSA generation algorithm, such as a 2048-bit RSAencryption algorithm run by the processing device 280 of the SCDE 180.RSA encryption algorithms, including a 2048-bit RSA encryptionalgorithm, are known in the art. The corresponding public key of theMerchant 1 is also signed by a Certificate of the processing center 150,which also acts as a trusted Certificate Authority.

A unique merchant ID and other credentials are also generated, as isknown in the art, and sent to the Merchant 1, in Step 430. If themerchant has multiple stores, a respective store ID may be generated foreach store. In addition, the Merchant 1 assigns terminal IDs to each PINpad terminal 130. Terminal IDs are used by the processing center 150 todetermine the PIN pad terminal 130 that sent the encrypted HTTPSenvelope requesting approval/denial of the payment so that the approvalor denial can be sent hack to the proper terminal.

The Merchant logs into the website of the processing center 150,authenticates itself using the merchant ID and credentials previouslyassigned by the processing center, and requests the Payment App 136 fromthe processing center. If the Merchant 1 is authenticated, the PaymentApp 136, which includes a Certificate of the processing center 150, isdownloaded to the merchant PIN pad terminals 130, in Step 440.

After the Payment App 136 is downloaded to a respective PIN pad terminal130, the PIN pad terminal requests the merchant public key. The publickey and signed certificate are downloaded to the PIN pad terminal 130,in Step 450. The PIN pad terminal 130 confirms that the public key hasbeen received by a trusted source, by comparing the certificate providedin with the Payment App 136 to the Certificate received with the publickey. If there is a match, the PIN pad terminal 130 accepts the publickey.

The public key, Payment App 136, and Merchant ID may be downloaded tothe PIN pad terminals 130 via the network 110, in secure HTTPSenvelopes, as described above, for example. If the merchant has multiplestores, then the store ID for the store in which the PIN pad 130 will belocated may also be loaded onto the respective PIN pad 130.

To securely store the merchant private key, the private key is treatedas an RES that is sent to the KMS 200 for encryption, via theapplications server 170 and the network 110, in Step 460. The KMS 200may encrypt the merchant private key with the KEK 202 that has beengenerated by the KMS for the processing center 150. The encryptedmerchant private key, also referred to as a merchant region encryptedsecret (“merchant RES′”), is returned to the processing center 150 withan associated KEK^(R) as discussed with respect to FIG. 5 .

The merchant RES′ and the KEK^(R) are received by the processing center150 from the KMS 200, in Step 470. The merchant RES′ and the KEK^(R) arestored in the secure database 300, in Step 480 in association with themerchant ID.

It is noted that Steps 460-480 may take place before, during, or afterSteps 430-450.

During a transaction, The PIN pad 130 encrypts transaction data and carddata with the merchant public key and sends the encrypted data to theprocessing center 150. The processing center 150 decrypts the encryptedinformation with the merchant's private key, as described in more detailbelow. FIG. 7 is a flowchart of an example of a method for retrieving anewly created merchant private key from the secure database 300. Thefirst time a transaction is received from a PIN pad terminal 130 of anewly registered Merchant 1, the merchant RES′ and associated KEK^(R)are retrieved from the database 300 by the processing device 280, basedon the merchant ID received with the transaction, in Step 490.

The merchant RES′ is sent to the KMS 200 for decryption, along with theKEK^(R), via the network 110, in Step 500. The merchant RES′ and KEK^(R)are sent in a secure HTTPS envelope, for example, as discussed above.The merchant RES′ is decrypted by the KMS 200 based on the KEKidentified by the KEK^(R) and sent back to the processing center 150 viathe network 110. The decrypted merchant RES (merchant private key) isreceived from the KMS in Step 510 and stored in the RAM 290 in Step 520.The merchant RES (private key) is now available for use in subsequentprocessing transactions.

In accordance with another embodiment of the invention, key rotation isfacilitated and security is further improved by periodically generatinga new public/private key pairs. The new key pair is generated by theprocessing device 280 as described with respect to Step 420 of FIG. 6 .The new public key is sent to the PIN pad terminal 130, as described inStep 450 of FIG. 6 , the new merchant private key is sent to the KMS 200for encryption, the encrypted merchant RES′ is received by theprocessing device 280, and the new merchant RES′ is stored in the securedatabase 300, as described with respect to Steps 460-480. The priormerchant RES′ is deleted from the secure database 300. The new merchantRES′, which is not yet stored in the RAM 290, is retrieved from thesecure database 300 when needed to decrypt encrypted data from a PIN padterminal 130, as described in FIG. 7 . The merchant RES is then storedin RAM 290 when needed next. The processing device 280 may be configuredto cause key rotation on a predetermined schedule, as is known in theart.

Card Number Encryption and Decryption

Card numbers, also referred to personal account numbers (“PANs”), arehighly sensitive information. In accordance with an embodiment of theinvention, PANs are encrypted by a multi-level encryption process forhigher security, based on salts, keys, and the KEK. Plain text carddata, which includes the PAN and other card related information, such asthe Card holder name, expiration date card verification value (“CVV”),PIN Verification Key, Pin Verification Value, card verification code,and/or EMV specific card information, for example, is also highlysensitive information. Card data that may be included in the plain textcard data is described in ISO/IEC 7813, for example. EMV specific cardinformation is described in ISO/IEC 7816 and EMV Books 1-4, availablefrom EMVCo LLC, for example. Plain text card data is encrypted via keys,such as AES keys, and the KEK.

FIG. 8 is a flowchart of an example of a method for preparing salts andkeys for encrypting sensitive information, such as PANs and plain textcard data, for example, in accordance with an embodiment of theinvention. While in this embodiment, both salts and keys are used, otherembodiments of the invention may only use salts to encrypt sensitiveinformation such as PANs, and other embodiments of the invention mayonly use keys to encrypt sensitive information such as plain text carddata, for example.

In the present embodiment of the invention, a first predetermined numberof salts and a second predetermined number of keys, are generated by theprocessing device 280 of the SCDE 180 during inception of the processingsystem 150 or at a later time, in Step 610. In this example, the firstpredetermined number of salts is 1009 salts, and the secondpredetermined number of keys is 379, which are large prime numbers.Other numbers of salts and AES keys may be generated and used.

In one example, the salts may be any length and may be non-random. Inanother example, the salts are cryptographically strong, as defined inFIPS 140-2, for example. In this example, each salt is 512 random bytesgenerated by a cryptographically secure random number generator, such asSecure Random in Java available from Oracle, Inc., for example.

The keys may be AES keys, such as 256-bit AES keys, for example. Asdiscussed above, an AES key is an advanced encryption standard (“AES”)key, such as a 256-bit AES key, for example. The AES keys could also be512-bit AES keys. Generation of a 256 and 512-bit AES keys are known inthe art. Other highly secure encryption techniques could also be used toencrypt the card information, such as Triple DES (3DES), for example,which is also known in the art.

The salts are concatenated into a binary large object (“blob”), whereone salt follows the next, by the processing device 280, in Step 620.The blob is sent to the KMS 200, via the applications server 170 and thenetwork 110, for encryption with the KEK 202 or another KEK, forexample, in Step 630. The KMS 200 encrypts the blob to form a blob RES′and returns the blob RES′ with a KEK^(R) to the processing device 280,via the network 110 and the applications server 170. The blob RES′ andthe KEK^(R) are received by the processing device 280 in Step 640 andstored in the secure database 300, in Step 650.

The AES keys are also sent to the KMS 200 for encryption, through theapplications server 170 and the network 110, in Step 660. The AES keysare each encrypted by the KMS 200 with the KEK 202 or another KEK toform AES key RESs′, which are received hack from the KMS, through thenetwork 110 and the applications server 170, in Step 670. The AES keyRESs′ and KEK^(R)s are also stored in the secure database 300, in Step650.

Decrypting RES's for Use

As noted above with respect to FIG. 7 , the first time a merchantprivate key is needed, the encrypted merchant private key, in the formof the merchant RES′, is retrieved from the secure database 300, sent tothe KMS 200 for decryption, received back as the merchant RES and storedin the RAM 290. Other merchant RESs′, the blob RES′, and the AES keyRESs′ are decrypted and stored in RAM for use during a hoot process, asdescribed below with respect to FIG. 9 .

The processing device 280 of the SCDE 180 is booted (restarted) in Step710. Booting may take place when a new version of the software runningthe processing device 150 is loaded, or when the software is updated, toimprove system operation, for example. After boot up, the processingdevice 280 sends a call to the secure database 300 to retrieve all themerchant RES′, blob RESs′, and AES key RESs′, along with the associatedKEK^(R), in Step 720. As noted above one or more KEK^(R)s may need to beretrieved.

The merchant RES′, blob RESs′, and AES key RES′s, along with theassociated KEK^(R), are received by the processing device 280, in Step730, and sent through the applications server 170 and the network 110 tothe KMS 200 for decryption based on the KEK 202 identified by theKEK^(R), in Step 740.

The decrypted RESs are received by the processing device from the KMS200, via the network 110 and applications server 170, in Step 750. Theblob RES, which is the concatenated salts, is parsed to separate theoriginal, individual salts, in Step 760. The concatenated salts may beparsed based on the known lengths of each salt, for example.

The individual salts, the merchant RESs, and the AES key RESs are storedin volatile memory, such as the RAM 290, by the processing device 280,in Step 770. The salt RESs and AES key RESs may be stored in respectivelists in the RAM 290, where each entry in the respective list isnumbered consecutively, or in an ordered list, for example. The orderedlist may comprise a numbered listing or table, in which each salt iscorrelated with a respective number, here 0-1008, respectively, and eachAES key is correlated with a respective number 0-378. The salts,merchant RESs, and AES key RESs are now available for use during theprocessing of payment transactions, and to securely store card numbersand other card information, for example.

As discussed herein, after a customer swipes their card or inserts theirEMV card in the PIN pad terminal 130, the PIN pad generates a secure,encrypted HTTPS envelope containing the card number (personal accountnumber (“PAN”)), along with other data including the transaction amount,a merchant ID, a store ID, PIN pad terminal ID, cardholder's name, cardexpiration date, and optionally customer's PIN Verification Key, PINVerification Value, card verification value (“CVV”), or cardverification code, and other information known in the art.

The data is encrypted by the PIN pad terminal 130 based on themerchant's public key, in accordance with an embodiment of theinvention. Other encryption techniques could be used. Also included inthe secure envelope is the merchant ID. The merchant ID is not encryptedby the public key, in this example. The PIN pad terminal 130 sends theHTTPS envelope to the processing center 150 via the network 110.

FIG. 10A is a flowchart of an example of a method of the processing thecard information received from the PIN pad terminal 130, by theprocessing center 150. The PIN pad terminal 130 generates the secureHTTPS encrypted envelope and sends it to the processing center 150, viathe network, in Step 810. The encrypted envelope is received by theprocessing device 280, via the network 110 and applications server 170,where it is decrypted, as is known in the art. The decrypted envelope isparsed by the processing device to identify the Merchant ID, in Step815. As noted above, the Merchant ID is not encrypted. The processingdevice 280 then searches the RAM 290 for the unencrypted merchant RES(private key), based on the Merchant ID, in Step 825.

It is then determined whether the merchant RES is stored in the RAM, inStep 825. If the merchant RES is stored in the RAM 290, (Yes in Step825), the merchant RES is retrieved from the RAM 290 by the processingdevice 280, in Step 830. If the merchant RES is not found in the RAM (Noin Step 825), then the processing device 280 searches the securedatabase 300 for the encrypted merchant RES′, in Step 840. As notedabove, the first time a transaction is received from a merchant afterregistration, the unencrypted merchant RES (private key) is not yetstored in RAM 290. Only the encrypted merchant RES′ (private key) isstored in the secure database 300. The processing device 280 may checkthe secure database for the encrypted merchant RES by sending themerchant ID and a request for the encrypted merchant RES correspondingto the merchant ID, to the secure database 300.

If the processing device 280 determines that the merchant RES′ is notstored in the secure database, then the merchant is not registered withthe processing center 150 or there is another problem. The transactioncannot be processed and the method ends in Step 850.

If the processing device 280 determines that the merchant RES′ is storedin the secure database, merchant RES′ is retrieved in Step 830. Themerchant RES′ is then sent to the KMS 200, decrypted, and, stored in theRAM 290, as described in Steps 500-520 in FIG. 7 . The RAM 290 may thenbe checked again in Step 820 of FIG. 10A and the process proceeds toStep 825. The merchant RES is retrieved in Step 830, as described above,and the process continues to Step 835 in FIG. 10B.

Continuing to FIG. 10B, The processing device 280 decrypts the encryptedcard data based on the merchant RES (private key), in a manner known inthe art, in Step 835. The result of the decryption is referred to asplain text card data, which includes the PAN, cardholder name,expiration date, CVV, and other items collected from the card, asdiscussed above and as is known in the art.

The plain text card data is parsed by the processing device 280 toidentify the PAN by the processing device 280, in Step 855. Theidentified PAN is encrypted by the processing device 280 to form anencrypted PAN or encrypted card ID, in Step 860. An example of anencryption process in accordance with an embodiment of the invention isdescribed below with respect to FIG. 11 . Other encryption methods maybe used, as well.

The processing device 280 searches the secure database 300 for theencrypted card ID to determine whether the encrypted card ID is alreadystored in the secure database 300, in Step 865. If Yes, thenhousekeeping functions may optionally be performed, in Step 870. Anexample of housekeeping in accordance with an embodiment of theinvention is described in more detail in FIG. 13 .

If the encrypted card ID is not found in the secure database 300 in Step860, then the plain text card data, including the PAN, is encrypted, inStep 875. An example of plain text card data encryption in accordancewith an embodiment of the invention is described below with respect toFIG. 12 . Other encryption techniques may be used, as well.

The encrypted card ID and corresponding encrypted plain text card data(also referred to as “encrypted card data”) is stored in the securedatabase, in Step 880. The stored encrypted card ID is used as a pointerto the location of the corresponding encrypted card data in the securedatabase 300, which facilitates retrieval of the encrypted card data.The encrypted card ID is also stored in the transactions database 270(see FIG. 3 ) for use by the applications server 170 to facilitateaccount look up for marketing and other functionality of the processingcenter 150 when also functioning as a payment gateway, as describedabove, in Step 885.

FIG. 11 is a flowchart of an example of PAN encryption to form theencrypted card ID, in accordance with an embodiment of the invention.The PAN is hashed by a hash function, by the processing device 280, inStep 910. The hash function may be an MD5 algorithm, for example, whichis known in the art. Alternatively, the hash function may be a SHA 256algorithm, for example.

A salt is selected for addition to the hashed PAN by determining aremainder of the hashed PAN (Step 910) divided by the firstpredetermined number of salts, here 1009, in Step 920. In other words,in this example, the processing device 280 calculates hashed PAN modulo1009. The salt in the list or table of salts corresponding to the numberof the remainder is selected in Step 930. For example, if the remainderis 10, then the tenth salt or the salt numbered 10 in the list isselected. The selected salt is retrieved, in Step 940.

The retrieved salt is combined with the PAN, in Step 950, to add entropyto the PAN. The salt may be added to the end of the PAN, for example.Alternatively, the salt may be added to the beginning of the PAN. Inanother example, a part, such as half, of the salt may be added to thebeginning of the PAN and the remainder may be added to the end of thePAN.

The combination of the PAN and the salt is encrypted by the processingdevice 280, in Step 960. The combination of the PAN and the salt may beencrypted by a destructive, non-reversible encryption function, forexample. A destructive function sufficiently transforms/destroys theformat and structure of the original data so that it cannot be recreatedbased on the encrypted data, with current technology, as is known in theart. A non-reversible function here means that it is not feasible toreverse the function to decrypt the data with current technology, as isknown in the art. An example of a destructive, non-reversible encryptionfunction that may be used is the password-based key derivation function2—key hashed message authentication code—secure hash 256 algorithm(“PBKDF2-HMAC-SHA256”), for example. SHA 256 is a hash function known inthe art. Other hash functions, such as MD5 may be used instead of SHA256, for example. HMAC-SHA 256 (or other such hash function) applies anauthentication code algorithm to the hashed function. Otherauthentication codes could be used, which are also known in the art,such as LMAC and PMAC. PBKDF2 is an iterative encryption function thathas been used to protect passwords. Other iterative encryption functionsthat may be used include crypt or scrypt, for example, which are alsoknown in the art. The method of FIG. 11 then returns to Step 860 of FIG.10B.

FIG. 12 is a flowchart of an example of a method for encrypting plaintext card data in Step 875 FIG. 10B, in accordance with the embodimentof the invention. The PAN is hashed by the processing device 280 in Step1010 (or the hash from Step 910 of FIG. 11 is used). Hashing of the PANis described above with respect to FIG. 11 . The same hash function or adifferent hash function as used in Step 910 in FIG. 11 , may be used inStep 1030 of FIG. 12 . The hashed PAN is divided by the secondpredetermined number of AES keys, here 379, to find the remainder(hashed PAN modulo 379), in Step 1020. The number of the AES key in theAES key list corresponding to the remainder in the AES key list isselected, in Step 1030. For example, if the remainder is 20, the AES keynumbered 20 in the list is selected. The selected AES key is retrievedin Step 1010. The retrieved AES key is used to encrypt the plain textcard data by the processing device 280, in Step 1050. The processingdevice 280 stores the encrypted card data in the secure database 300, inStep 1060.

Housekeeping

FIG. 13 is flow chart of an example of housekeeping, in accordance withan embodiment of the invention. Housekeeping is an optional function,which enables updating of information in stored card data records for apreviously used card, such as the expiration date, cardholder name, andEMV information, for example, that may have changed since the last timethe card was processed by the processing center 150. For example, a newcard may be issued with the same PAN but a different expiration date.

A record corresponding to the encrypted card information received inStep 815 of FIG. 10A is retrieved by the processing device 280, in Step1110 of FIG. 13 . The record contains encrypted plain text card data, asdiscussed above. In this example, the record containing the encryptedplain text card data is stored in the secure database 300, and theencrypted card ID corresponding to the encrypted plain text card data,which is the encrypted personal account number derived from on the plaintext card data, is also separately stored in the secure database 300 asa identifier to point to the location of the record in the securedatabase 300, as discussed above. This facilitates location andretrieval of the record. The received plain text card data with have thesame personal account number (“PAN”) as the corresponding record.Searching for the PAN from the received plain text card data thereforeenables retrieval of the corresponding record.

The AES key used to encrypt the retrieved encrypted card data isidentified by the processing device 280, in Step 1120. In this example,the key is identified from the AES key list based on the hashed PANmodulo 379, as discussed above with respect to FIG. 12 . The encryptedcard data may be decrypted by the processing device 280 based on thesame AES key used to encrypt the card data, in a manner known in theart, in Step 1130.

Different types of data in the plain text card data in located indifferent fields, as is known in the art. For example, the expirationdate, cardholder name, CVV, and other types of information discussedabove are located in different, respective fields. The processing device280 parses the decrypted plain text card data from the record, and thedecrypted plain text card data from the decrypted card information, inStep 1140, to separate the information in the respective fields. Theprocessing device 280 may use a card template to locate respectivefields, as is known in the art. All fields may be checked or only fieldsthat could have changed, such as the expiration date, cardholder name,and certain EMV information, such as EMV processing instructions from anissuing bank or card brand, for example. The provision of processinginstructions on an EMV card by an issuing bank via scripts is describedin U.S. patent application Ser. No. 15/699,090, which was filed on Sep.8, 2017, is assigned to the assignee of the present invention, and isincorporated by reference herein. The card brand may also provideprocessing instructions.

The information in the respective fields of the decrypted card data isthen compared to the information in the corresponding fields of theplain text card data of the record, in Step 1150. The fields may becompared, field by field. If they are the same (No in Step 1150), thenthe stored card data does not need to be updated, and the processreturns to Step 875 of FIG. 10B, where the plain text card data isencrypted again and stored in the record in the secure database 300, inSteps 880 and 885.

If the information in any field in the plain text card data does notmatch the information in the corresponding field of the decrypted carddata (Yes in Step 1160), then the processing device 280 replaces thecard data stored in the field of the plain text card data by thecorresponding information in the corresponding field of the plain textcard data, in Step 1180. For example, if an expiration date of the cardhas been recently changed, but the card number (PAN) has not beenchanged, then the expiration date in the expiration date field of theplain text card data will not match the expiration date in thecorresponding field of the decrypted card data. The expiration datafield of the plain text card data is then updated, in Step 1190, to theexpiration date of the current plain text card data. A cardholder namemay also change without changing the PAN, for example.

The plain text card data of the record is then encrypted, as describedabove in Step 875 of FIG. 10B and stored in the secure database 300 inStep 880. The processing device 280 logs updates to the plain text carddata in the record in a log stored in the secure database 300, forexample. The logged data may be used by the processing center 150 toperform debugging in the event of errors, analytics on card data updatefrequency, and/or heuristics based on card type, for example. If theyare the same (No in Step 1150), then the stored card data does not needto be updated, and the process returns to Step 875 of FIG. 10B, wherethe plain text card data is encrypted again and stored in the record inthe secure database 300, in Step 880.

Embodiments of the invention may be used to update other types ofencrypted records stored in a database, including health or medicalrecords, for example. Updateable fields in medical records may include apatient's name, address, medications, weight, and/or diagnosis, forexample. A medical template may be used to locate respective fields.

Region Redundancy

As discussed above, redundancy in case of a failure with an availabilityzone (AZ) may be provided by using different power supply companies,using different network providers to back up data, and storing the datain other storage devices in other AZs, for example. In accordance withan embodiment of the invention, redundancy across regions is providedthrough the use of one or more respective KMSs in multiple regions.

FIG. 14 is a block diagram of an example of a portion of a card paymentprocessing system 1200 that provides region redundancy in accordancewith an embodiment of the invention. Items common to the system of 100of FIGS. 1-13 are commonly numbered. The Merchant 1, 2, 3 . . . N,payment processors 160 a-160 c, card brand 165, and bank 168 of FIG. 1are not included in FIG. 14 for use of illustration. It is understoodthat those entities may interact with the processing center 150 in FIG.14 in the same way as described with respect to FIGS. 1-13 .

In the example of FIG. 14 , a KMS 1 (numbered 200), is shown in a cloudhosted Region 1 of the cloud hosting provider, along with the processingcenter 150. In this example, the processing center 150 and KMS1 are bothin Region 1 and KMS1 is the “nearest neighbor” (the KMS closestgeographically) to the processing center 150. A second KMS2 and a thirdKMS3 are also provided in Region 2 and in Region 3 of the cloud hostprovider, respectively. Each KMS1, KMS2, KMS3 generates a unique KEK1,KEK2, KEK3, respectively, for the processing center 150 upon the requestof the processing center, as indicated in FIG. 14 . KEK requests to eachKMS are made through the AWS console as described above. In otherexamples, more KMSs may be provided in additional regions, or only twoKMSs are provided in two regions. Each KMS1, KMS2, KMS3 also generate arespective KEK1 ^(R), KEK2 ^(R), KEK3 ^(R) to identify each respectiveKEK1, KEK2, KEK3. In accordance with this embodiment of the invention atleast two (2) KMS are provided in two (2) different regions such as KMS1and KMS2. The additional components of the KMS 200 discussed above, arealso provided in each KMS1, KMS2, KMS3.

The processing device 280 communicates with KMS1, KMS2, and KMS3 via theapplications server 170 and the network 110. Redundancy across Region 1,Region 2, and Region 3 is provided in this example by the processingdevice 280 sending each merchant RES, blob RES, and AES key RESs to theKMS1, KMS2, and KMS3 of each region for encryption with the respectiveKEK1, KEK2, and KEK3 to form Merchant RES1′. RES2′, RES3′, blob RES1′,RES2′, RES3′, and AES key RES1 s′, RES2 s′, RES3 s′, respectively. If arespective RES′ cannot be decrypted by the KMS that encrypted it,another KMS may be requested to decrypt a corresponding RES′ that wasencrypted by that KMS.

In one example, encrypted merchant RES1′, RES2′, RES3′ blob RES1′,RES2′, RES3′, and AES key RES1′s, RES2′s, RES3′s based on each KEK1,KEK2, KEK3 are received by the processing system 150 and stored. If theKMS 1 is down or otherwise not responsive to requests to decrypt RES1′swith KEK1, for example, then RES2′s or RES3′s may be sent to KMS2 and/orKMS3 in Regions 2 and 3 for decryption based on KEK2 or KEK3,respectively. The processing center 150 may thereby continue to operate,even if KMS1 and KMS2 go down.

FIG. 15 is an example of a flowchart of the encryption of the blob ofsalts and the AES keys, in a region redundant system 1200, in accordancewith this embodiment of the invention. After the salts and AES keys aregenerated and a blob of salts formed, as described in FIG. 8 , forexample, the blob and AES keys are sent by the processing device 280 toeach KMS, here KMS1, KMS2, KMS3 for encryption with a respective KEK1,KEK2, KEK2, in Step 1310.

The blobs KMS1, KMS2, KMS3, encrypted by KEK1, KEK2, KEK3, respectively,are referred to as encrypted blob RES1′, RES2′, RES3′ respectively, inStep 1310. The AES keys encrypted by KMS1, KMS2, KMS3 with KEK1, KEK2,KEK3 are referred to as AES key RES1′s, RES2′s, and RES3′s, and KEK1^(R), KEK2 ^(R), KEK3 ^(R), and are received by the processing device280 from each KMS1, KMS2, KMS3, via the network 110 and applicationsserver 170, in Step 1320. Respective encrypted blobs RES1′, RES2′, RES3′are combined by the processing device 280 into a single object and theobject is stored by the processing device 280 in the secure database300, in association with the KEK^(R) 1, KEK^(R) 2, KEK^(R) 3, in Step1330.

Each AES key RES1′, RES2′, RES3′ for a respective AES key are alsoformed by the processing device 280 into respective objects and storedby the processing device 280 in the secure database 300, in Step 1330,in association with the KEK^(R) 1, KEK^(R) 2, KEK^(R) 3.

FIG. 16 is an example of a process for encrypting merchant private keysin the redundant system 1200 of FIG. 14 , in accordance with anembodiment of the invention. When a respective merchant registers withthe processing center 150, in Step 1410, a public and private key aregenerated by the processing device 280 in Step 1420, as described abovewith respect to FIG. 6 . The merchant private key is sent by theprocessing device 280 to KMS1, KMS2, KMS3 for encryption, via theapplications server 170 and the network 110, in Step 1430. The merchantRES1′, RES2′, RES3′ are received by the processing device 280 in Step1450 and formed into a single object, in Step 1440. The object is storedin the secure database 300, by the processing device 280, along with thereceived KEK1 ^(R) KEK2 ^(R), KEK3 ^(R), in Step 1460.

FIGS. 17A-17B is an example of the flowchart of an example of a bootprocess in the system 1200 of FIG. 14 , in accordance with an embodimentof the invention. During a boot, all merchant RES′ objects, blob RES′objects, and AES Key RES′ object are retrieved from the service databaseby the processing device 280, along with associated KEK^(R) 1 s, KEK^(R)2 s, KEK^(R) 3 s in Step 1510. The objects are parsed into their threerespective RES1′s, RES2′s, RES3′s by the processing device 280, in Step1520. The objects may be parsed based on the expected lengths of theRES1′, RES2′, RES3′, which are known based on the lengths of theunencrypted data and the encryption methods applied, for example.Alternatively, the RES′ object may be in the form of an array in whichthe first element is the respective RES1′, the second element is therespective RES2′, and the third element is the RES3′.

In Step 1530, the RES1′s and associated KEK^(R) 1 s are sent by theprocessing device 280 to KMS1 for decryption, via the applicationsserver 170 and the network 110. In this example, KMS1 and the processingcenter 150 are both in Region 1, and the KMS1 is the nearest neighbor tothe processing system 150.

The processing device 280 waits a predetermined period of time toreceive the decrypted merchant, blob, and AES key RES1 s, in Step 1540.If the decrypted RES1 s are received within the predetermined period oftime, (Yes in Step 1540), the merchant, blob, and AES key RES is arestored in the RAM 290, in Step 1550. If not (No in Step 1540), then KMS1may have failed. Decryption requests in this example are sent to KMS1first because KMS1 is the closest KMS geographically to the processingcenter 150. Communication between the processing center 150 and the KMS1is therefore faster than the communication between the processing centerand KMS2 and KMS3.

The processing device 280 then sends the retrieved RES2′s to KMS2 andassociated KEK^(R) 2 s, via the applications server 170 and the network110, for decryption, in Step 1560. In this example KMS2 is the nextnearest neighbor after KMS1. The processing device 280 waits apredetermined period of time to receive the decrypted merchant, blob,and AES key RESs, in Step 1570. If the decrypted RES2 s are received inthe predetermined period of time, then the merchant, blob, and AES keyRES2 s are stored in the RAM 29, in Step 1580.

If not, then KMS2 may have failed and the processing device 280 sendsthe retrieved RES3′s and associated KEK^(R) 3 s to KMS3, in Step 1590.The processing device 280 waits a predetermined period of time toreceive the decrypted merchant, blob, and AES key RES3 s, in Step 1600.If the merchant, blob, and AES key RES3 s are received in thepredetermined period of time, then the merchant, blob, and AES key RES3s are stored in the RAM 290, in Step 1610. If not, then the process endsin Step 1620. Such an occurrence is very unlikely, but possible.

In the example of FIGS. 17A-17B, the KMSs are communicated with in theorder of their geographic proximity. In this case, the softwarecontrolling the processing device 280 is configured to cause theprocessing device to send the respective RES1′s, RES2′s, RES3′s to KMS1KMS2, KMS3, respectively, in that order.

In another example, the respective RES1′, RES2′, RES3′ are sent to theKMS1, KMS2, KMS3, respectively, based on the result of a random numbergenerator, for example. The random number generator may generate a listof the KMSs in a random order and the processing device 280 then checksthe list to determine which KMS to contact first, second, and third,etc. Other selection schemes may be used. The process of FIGS. 17A-17Bmay be suitably modified by one of ordinary skill in the art to selectthe order of requesting decryption from the KMS1, KMS2, and KMS3 inaccordance with different selection schemes.

Examples of implementations of embodiments of the invention aredescribed above. It would be apparent to one of ordinary skill in theart that modifications may be made to the examples above withoutdeparting from the spirit and scope of the invention, which is describedin the following claims.

We claim:
 1. A method of encrypting and decrypting data comprising:sending, by a server computer system, sensitive information to a firstcryptographic processing system of a first cloud computing system togenerate first encrypted sensitive information by performing encryptionof the sensitive information with a first encryption key generated byand stored by the first cryptographic processing system; storing, by theserver computer system, the first encrypted sensitive informationreceived from the first cryptographic processing system in a firstdatabase; sending, by the server computer system, the sensitiveinformation to a second cryptographic processing system of a secondcloud computing system, different from the first cloud computing system,to generate second encrypted sensitive information by performingencryption of the sensitive information with a second encryption keygenerated by and stored by the second cryptographic processing system;storing, by the server computer system, the second encrypted sensitiveinformation received from the second cryptographic processing system ina second database, in response to receiving encrypted transaction datafrom a user device, sending, by the server computer system, the firstencrypted sensitive information to the first cryptographic processingsystem, receiving, by the server computer system from the firstcryptographic processing system, a decrypted version of the firstsensitive information, and storing, in a volatile memory of the servercomputer system, the decrypted version of the first sensitiveinformation, wherein the server computer system decrypting the encryptedtransaction data using the decrypted version of the first sensitiveinformation.
 2. The method of claim 1, further comprising: in responseto determining that the decrypted version of the first sensitiveinformation is not received from the first cryptographic processingsystem within a first predetermined period of time, sending, by theserver computer system, the second encrypted sensitive information tothe second cryptographic processing system; receiving, by the servercomputer system from the second cryptographic processing system, adecrypted version of the second sensitive information; and storing, inthe volatile memory of the server computer system, the decrypted versionof the second sensitive information, wherein the server computer systemdecrypting the encrypted transaction data using the decrypted version ofthe second sensitive information.
 3. The method of claim 1, furthercomprising: generating, by the server computer system, a public key,private key pair for a user of the server computer system; generating,by the server computer system, an identifier for the user; sending, bythe server computer system, a public key of the public key, private keypair to the user device; and storing, by the server computer system, anencrypted version of a private key of the public key, private key pair.4. The method of claim 3, wherein storing, by the server computersystem, the encrypted version of the private key of the public key,private key pair further comprises: sending, by the server computersystem, the private key as the first sensitive information to the firstcryptographic processing system of the first cloud computing system forencryption using the first encryption key generated by the firstcryptographic processing system; sending, by the server computer system,the private key as the second sensitive information to the secondcryptographic processing system of the second cloud computing system forencryption using the second encryption key generated by the secondcryptographic processing system; storing a first encrypted version ofthe private key as the first encrypted sensitive information receivedfrom the first cryptographic processing system in the first database;and storing a second encrypted version of the private key as the secondencrypted sensitive information received from the second cryptographicprocessing system in the second database.
 5. The method of claim 3,wherein the user device comprises a PIN pad terminal device associatedwith the user.
 6. The method of claim 5, further comprising: receiving,from the user device, the encrypted transaction data, the encryptedtransaction data encrypted by the user device using the public key, andthe encrypted transaction data containing a personal account number of acard, a transaction amount, a user identifier, an identifier of the userdevice, a name associated with the card, an expiration date of the card,and a PIN verification key, a PIN verification value, a cardverification value, a card verification code, or a combination thereof.7. The method of claim 1, wherein the first database and the seconddatabase are the same database.
 8. The method of claim 1, wherein thefirst database is a secure database and the second database is a securedatabase.
 9. The method of claim 1, wherein the first cryptographicprocessing system comprises a first key management service, a firsthardware security module, or a combination thereof, and the secondcryptographic processing system comprises a second key managementservice, a second hardware security module, or a combination thereof.10. A non-transitory computer readable storage medium, havinginstructions stored thereon, which when executed by a server computersystem, cause the server computer system to perform operations,comprising: sending, by the server computer system, sensitiveinformation to a first cryptographic processing system of a first cloudcomputing system to generate first encrypted sensitive information byperforming encryption of the sensitive information with a firstencryption key generated by and stored by the first cryptographicprocessing system; storing, by the server computer system, the firstencrypted sensitive information received from the first cryptographicprocessing system in a first database; sending, by the server computersystem, the sensitive information to a second cryptographic processingsystem of a second cloud computing system, different from the firstcloud computing system, to generate second encrypted sensitiveinformation by performing encryption of the sensitive information with asecond encryption key generated by and stored by the secondcryptographic processing system; storing, by the server computer system,the second encrypted sensitive information received from the secondcryptographic processing system in a second database; in response toreceiving encrypted transaction data from a user device, sending, by theserver computer system, the first encrypted sensitive information to thefirst cryptographic processing system; receiving, by the server computersystem from the first cryptographic processing system, a decryptedversion of the first sensitive information; and storing, in a volatilememory of the server computer system, the decrypted version of the firstsensitive information, wherein the server computer system decrypting theencrypted transaction data using the decrypted version of the firstsensitive information.
 11. The non-transitory computer readable storagemedium of claim 10, further comprising: in response to determining thatthe decrypted version of the first sensitive information is not receivedfrom the first cryptographic processing system within a firstpredetermined period of time, sending, by the first server computersystem, the second encrypted sensitive information to the secondcryptographic processing system; receiving, by the server computersystem from the second cryptographic processing system, a decryptedversion of the second sensitive information; and storing, in thevolatile memory of the server computer system, the decrypted version ofthe second sensitive information, wherein the server computer systemdecrypting the encrypted transaction data using the decrypted version ofthe second sensitive information.
 12. The non-transitory computerreadable storage medium of claim 10, further comprising: generating, bythe server computer system, a public key, private key pair for a user ofthe server computer system; generating, by the server computer system,an identifier for the user; sending, by the server computer system, apublic key of the public key, private key pair to the user device; andstoring, by the server computer system, an encrypted version of aprivate key of the public key, private key pair.
 13. The non-transitorycomputer readable storage medium of claim 12, wherein storing, by theserver computer system, the encrypted version of the private key of thepublic key, private key pair further comprises: sending, by the servercomputer system, the private key as the first sensitive information tothe first cryptographic processing system of the first cloud computingsystem for encryption using the first encryption key generated by thefirst cryptographic processing system; sending, by the server computersystem, the private key as the second sensitive information to thesecond cryptographic processing system of the second cloud computingsystem for encryption using the second encryption key generated by thesecond cryptographic processing system; storing a first encryptedversion of the private key as the first encrypted sensitive informationreceived from the first cryptographic processing system in the firstdatabase; and storing a second encrypted version of the private key asthe second encrypted sensitive information received from the secondcryptographic processing system in the second database.
 14. Thenon-transitory computer readable storage medium of claim 12, wherein theuser device comprises a PIN pad terminal device associated with theuser.
 15. The non-transitory computer readable storage medium of claim14, further comprising: receiving, from the user device, the encryptedtransaction data, the encrypted transaction data encrypted by the userdevice using the public key, and the encrypted transaction datacontaining a personal account number of a card, a transaction amount, auser identifier, an identifier of the user device, a name associatedwith the card, an expiration date of the card, and a PIN verificationkey, a PIN verification value, a card verification value, a cardverification code, or a combination thereof.
 16. The non-transitorycomputer readable storage medium of claim 10, wherein the first databaseand the second database are the same database.
 17. The non-transitorycomputer readable storage medium of claim 10, wherein the first databaseis a secure database and the second database is a secure database. 18.The non-transitory computer readable storage medium of claim 10, whereinthe first cryptographic processing system comprises a first keymanagement service, a first hardware security module, or a combinationthereof, and the second cryptographic processing system comprises asecond key management service, a second hardware security module, or acombination thereof.
 19. A server computer system, comprising: anon-volatile memory and a volatile memory; and a processor coupled withthe volatile memory configured to: send sensitive information to a firstcryptographic processing system of a first cloud computing system togenerate first encrypted sensitive information by performing encryptionof the sensitive information with a first encryption key generated byand stored by the first cryptographic processing system; store, in thenon-volatile memory, the first encrypted sensitive information receivedfrom the first cryptographic processing system in a first database; sendthe sensitive information to a second cryptographic processing system ofa second cloud computing system, different from the first cloudcomputing system to generate second encrypted sensitive information byperforming encryption of the sensitive information with a secondencryption key generated by and stored by the second cryptographicprocessing system; store, in the non-volatile memory, the secondencrypted sensitive information received from the second cryptographicprocessing system in a second database; in response to receipt ofencrypted transaction data from a user device, send, by the servercomputer system, the first encrypted sensitive information to the firstcryptographic processing system; receive, from the first cryptographicprocessing system, a decrypted version of the first sensitiveinformation; and store, in the volatile memory of the server computersystem, the decrypted version of the first sensitive information, theserver computer system decrypting the encrypted transaction data usingthe decrypted version of the first sensitive information.
 20. The systemof claim 19, wherein the processor is further configured to: when thedecrypted version of the first sensitive information is determined notto have been received from the first cryptographic processing systemwithin a first predetermined period of time, send the second encryptedsensitive information to the second cryptographic processing system;receive, from the second cryptographic processing system, a decryptedversion of the second sensitive information; and store, in the volatilememory, the decrypted version of the second sensitive information,wherein the server computer system decrypting the encrypted transactiondata using the decrypted version of the second sensitive information.